home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 9513 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: malloc question
  5. Date: 11 Mar 1996 10:36:19 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4i1kq3$2m0@solutions.solon.com>
  8. References: <4htonk$350@news.hklink.net> <314318AF.30F@iperbole.bologna.it> <4hvaj4$laj@solutions.solon.com> <AD69AACE9668D78B0@mcdiala09.it.luc.edu>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <AD69AACE9668D78B0@mcdiala09.it.luc.edu>,
  12. Verne Arase <VArase@varase.it.luc.edu> wrote:
  13. >Well, in the general case it _could_ hide an error.
  14.  
  15. >In this specific case, however, it _never_ hides an error. If malloc is
  16. >used in its standard context, we are simply coercing a slab of memory
  17. >aligned to the most stringent boundaries into a pointer of the desired
  18. >type.
  19.  
  20. Which does *nothing*, because void pointers always convert to the desired type
  21. silently and automatically.
  22.  
  23. Further, it *did* hide an error in the specific case; <stdlib.h> was not
  24. included, and there was no prototype in scope.
  25.  
  26. >Provided the associated header is included (and the memory model doesn't
  27. >change through some devious, manual manipulation), you are _always_ safe in
  28. >coercing a malloc allocated block of memory into the desired pointer type.
  29.  
  30. And you are _always_ redundant doing so, unless you're passing to a varaidic
  31. function or one with no prototype in scope.
  32.  
  33. >This is one reason I stopped participating in C conferences; there's always
  34. >some language lawyer who'll tell a novice that a cast is an evil (even if
  35. >it has to do with casting a char * to an unsigned char * for use in a file
  36. >name). What they normally fail to tell you is that any code much beyond the
  37. >sophistication of "Hello World" practically requires casts to produce
  38. >workable code.
  39.  
  40. Bullshit.  I have written vast applications which, through careful use of void
  41. pointers, need no casts at all.  90% of casts in code I see posted to
  42. comp.lang.c are useless; many of them are wrong.
  43.  
  44. >IMO, making a char a signed quantity (along with the infamous misplacement
  45. >of the boolean and operator's priority) have made more C programmer's lives
  46. >miserable than any other construct in any other language (that I've
  47. >encountered).
  48.  
  49. char is not a signed quantity.  char is a quantity which may be signed or
  50. unsigned.
  51.  
  52. It's a question of usage.  An unspecified short, int, or long is *always*
  53. signed, so it is clearly desireable for char to be signed.  EOF is negative,
  54. and the getc family all return unsigned char or EOF, so it is clearly
  55. desireable for char to be unsigned.
  56.  
  57. >Sure there are constructs that'll get you in trouble. But let us not forget
  58. >that C is the original "gun, bullet, foot" language, and requires care in
  59. >its use and execution.
  60.  
  61. Precisely, which is why it is good to learn not to make redundant casts.
  62.  
  63. If you don't put in casts, you will get warnings for any conversion not
  64. normally correct.  This is helpful.
  65.  
  66. -s
  67. -- 
  68. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  69. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  70. FUCK the communications decency act.  Goddamned government.  [literally.]
  71. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  72.